photo by karen kuehn

最近看到一個詞非常有趣—Cargo Cult 貨物崇拜。這個名詞的由來來自二次大戰，美軍在太平洋小島蓋了一個臨時的軍用基地 ，當美軍從軍機走出並帶來許多物資時，當地的土著對這樣的景象感到非常震驚，彷彿看到神駕著巨大的鐵鳥帶來了豐收。因此在二次大戰結束美軍離開後，當地的土著開始模仿製造木頭的飛機、看似像跑道的景象，但其實都只有模仿到皮毛，就開始敬拜美軍留下的貨物跟衣服，後來甚至形成一種宗教信仰，開始敬拜美軍留下的貨物跟衣服。

而這樣的行為被稱為「貨物崇拜」，所以後來該詞也被拿來泛指對外來的新鮮事物產生過度崇拜並進一步模仿，通常帶有負面的意味，因為模仿得不是很好?。

而當我們接觸到敏捷或Scrum 但卻還未了解的很深入的時候，的確會出現或多或少的貨物崇拜，底下列舉了前輩根據 Stefan Wolpers 的敏捷貨物清單的整理，非常有趣但卻很貼切，大家可以一起跟我來檢核一下自己的敏捷團隊：

1. 沒有溝通（產品的）願景和策略
2. 產品藍圖和發佈日期在一年前就由CTO規劃好了
3. 組織內沒有人跟顧客對談
4. CTO和利害關係人堅持所有的改動都要經由他們批准
5. 因為保密資安等理由，禁止使用實體的看板或告示
6. 利害關係人直接跟CTO對談，跳過Product Owner
7. 由利害關係人來決定交付產品增量，而不是Product Owner
8. 專案/產品只有在完成時才交付，而不是增量式的交付
9. 避免利害關係人直接跟開發團隊對談
10. Product Backlog是由一個產品委員會決定的
11. 就算對功能的價值有所懷疑，但還是硬上了（為了年終獎金…）
12. 業務為了成交，答應客戶增加目前不存在的功能，而Product Owner不知情
13. 就算是不重要的問題，也有固定的進度表和期限
14. 負責產品管理的角色沒有取得商業智能（BI）資訊的權限，沒有充足的資訊和數據幫助決定
15. 利害關係人使用需求文件來和產品與工程部門溝通
16. Product Owner大部分的時間都在撰寫和管理使用者故事（User Stories）
17. 在Sprint開始後不久Sprint Backlog就變了
18. 專門成立一個開發團隊來修Bugs和處理小的需求
19. 利害關係人沒有參加過Scrum活動（例如Sprint Planning和Sprint Review）
20. 主要是用『速率（Velocity）符合當初的承諾』來當指標評估Scrum是否成功
21. 開發人員沒有參與創造使用者故事
22. 同時處理的專案數量和工作會改變開發團隊的人數跟組成方式
    1. 在Daily Stand up中團隊成員對ScrumMaster報告
23. 定期舉行自省會議（Retrospectives），但沒有改變隨之發生
24. 開發團隊並不是跨功能（Cross Functional），而要靠其他團隊或部門才能完成工作

評分結果

平均0 – 2個是：太神奇了，可以跟我（作者）聯絡你們是怎麼辦到的嗎？
平均3 – 5個是：事情看起來是在對的方向發展
平均6 – 8個是：有可改善的空間，蠻多的
平均9 – 14個是：如果你們不是剛剛開始跑敏捷，也許可以考慮換個實行方式
平均15 – 20個是：試試重新開始導入敏捷吧，目前的安排在你們組織沒有用
平均21 – 25個是：要嘛是你們還沒開始跑敏捷，要嘛是在傳統的專案方式外包裝了敏捷的糖衣，良心建議：這沒有用的。

我檢核我過去的團隊經驗竟然也命中12個，看到這裡的夥伴，也大方的跟我分享你的團隊命中幾個吧XD